The present invention relates to a method and/or a system and/or a network node for optimizing an establishment of a communication connection between a mobile node and a correspondent node in a packet based communication network. The present invention relates in particular to a method and/or a system and/or a network node in a 3rd generation wireless communication network where the Session Initiation Protocol (SIP) is used as a multimedia call control protocol and the Internet Protocol (IP) is used as a data transport protocol (for example Mobile IPv6 is used as the IP Mobility protocol).
The last few years have seen communication networks, in particular wireless networks, increasingly extending deployments and coverage all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), Institute for Electrical and Electronic Engineers (IEEE), and the like are working on standards for 3rd generation telecommunication network and multiple access environments, such as GPRS/UMTS (General Packet Radio Service/Universal Mobile Telecommunications System), Wireless Local Area Network (WLAN), cdma2000 (code division multiple access) and the like. The aim of 3rd generation telecommunication systems is to provide improved services for users in comparison to present 2nd generation systems, such as GSM, in particular with regard to data transmissions, for example, in multimedia applications.
With the convergence of voice and data networks, new communication networks, for example, 3rd generation wireless networks, are evolving to adopt packet switched networks to deliver voice and data services over this type of network. In order to support voice and multimedia by a packet data network based, for example, on the Internet Protocol (IP), the Internet Protocol Multimedia (IM) core network subsystem (referred to hereinafter as IM subsystem) is provided. The IM subsystem can control voice and multimedia calls and sessions as well as interconnections to other networks, such as other UMTS networks, Public Switched Telecommunication Networks (PSTN) and the like. In the IM subsystem, IP and other protocols standardized by the IETF are used. IPv6 is the mandated network layer protocol for the IM subsystem, for example, in 3GPP.
For performing registration and call control for the user equipment in the IM domain or subsystem, for example, the Session Initiation protocol (SIP) is used as a signaling protocol. SIP is an application layer protocol for establishing, changing and tearing down of sessions between two or more participants. Multimedia session setup also requires QoS (Quality of Service) to be setup for the media path. The control of the call relates to inviting and synchronizing the various participants in the call, i.e. the respective terminal nodes (user equipment and correspondent node) and involved network elements. Furthermore, information about the characteristics of the terminating equipment and the speech codecs to be used between the users (i.e. user equipment and correspondent node) can be announced by the participants. This information is known as the session description, and could include, for example, the codecs used for the speech and the bandwidth needed for the speech paths. SIP essentially provides the invitation and synchronization of the participants, and it uses session description protocol (SDP) to describe the session. SIP and SDP are standardized by the IETF.
As call control functional entity in the IM domain a so-called call state (or session) control function (CSCF) is used. CSCFs are classified into several types, such as Proxy-CSCF (P-CSCF), Serving CSCF (S-SCSF) and Interrogating CSCF (I-CSCF). The S-CSCF controlling a call of the user equipment is located, for example, in the network to which the user is subscribed, i.e. the home network of the user. The P-CSCF is an entry point for the connection of the user equipment to the network and is located in the network in which the user equipment is currently located. When the user equipment has roamed to another network than its home network the P-CSCF is part of the visited network. The P-CSCF can also be a part of the home network when it interfaces to a gateway network element, such as a GGSN (Gateway GPRS Support Node). The I-CSCF is used to determine the S-CSCF to be assigned to a user equipment (UE) for registration or when a mobile terminating call is received in the IM subsystem. A Home Subscriber Subsystem (or Server) (HSS) is also provided in the user's home network which provides user profile information.
SIP messages are usually transported by the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). However, SIP is transport independent and other protocols, such as the Stream (or Simple) Control Transmission Protocol (SCTP), can be used to provide a higher level of quality than TCP.
The UE needs to establish, for example, a packet data protocol (PDP) context in order to be able to send and receive IP datagrams. Only after a PDP context has been established the UE is able to exchange messages to and via the IMS. The connection between the user equipment and the IM subsystem is established via a Radio Access Network (RAN), for example UTRAN (UMTS Terrestrial RAN), and the mobile packet core which may comprise of a SGSN (Serving GPRS Support Node) and the GGSN (Gateway GPRS Support Node), which essentially form the packet data core of the UMTS network (in the case of a cdma2000 network it is the PDSN (Packet Data Serving Node)).
The mobile node (or UE) may use, for example, Mobile IPv6 for achieving IP mobility. With Mobile IPv6, the mobile node has a home address (HoA) and a care-of-address (CoA). The home address is the IP address assigned by the home network and is the address used to reach a mobile node. The care-of-address is an IP address that is derived from the current point of attachment. The mobile node indicates its care-of-address to a server, e.g. its home agent (HA), via a binding update procedure, and IP routing/tunnelling ensures that packets are routed to the mobile node at its current care-of-address (location) even when packets are sent to its home address. A mobile changes its care-of-address when the access router that it is attached to changes. Hence if the mobile were to move, for example, to a different PDSN, it would obtain a new care-of-address.
When a communication connection between a user equipment UE (or mobile node MN) and a correspondent node (CN) has been established, for example, via SIP signaling, and in case MIPv6 is used to support IP level mobility, a procedure known as route optimization can be executed by the terminal nodes. By route optimization data can be directly transmitted between the MN and the CN without having to traverse through the HA. Route optimization is initiated, for example, by the MIPv6 MN by sending a Binding Update to the CN to provide the MN's CoA corresponding to the MN's Home Address (MN HoA). For this purpose, the MN needs to know the CN's IP address so as to be able to send the binding update to the CN. The IP address of the CN is known or provided, for example, when the CN first sends a packet to the MN's HoA which results in the packet being tunneled by the MN's HA to the MN. Now, the MIP module of the MN knows the destination IP address of the CN and reacts by sending a Binding Update also to the CN. In order to ensure the security of the Binding Update, i.e. to ensure for the CN that the CoA provided by the MN is actually owned by the MN, a Return Routability test is mandated by MIPv6 specification (for example in Internet Draft “Mobility Support in IPv6” (draft.ietf-mobileip-ipv6-19.txt)). Such a Return Routability test requires the exchange between the MN and the CN of a series of messages that are defined in the Mobile IPv6 specification.
Referring to FIG. 2 consisting of FIGS. 2A, 2B, and 2C, an example for a SIP call establishment according to 3GPP is described first. It is to be noted that the described scenario is only one from a plurality of examples. Further information with regard to SIP call establishment scenarios are derivable, for example, from 3GPP 24.228 V5.2.0 (2002-09) “Signalling flows for the IP multimedia call control based on SIP and SDP”, Stage 3, Release 5.
When a call between the UE and the CN is to be established, the UE determines a set of codecs that it is capable of supporting for the session and which are desired for the session, and builds up SDP comprising, for example, bandwidth requirements, connection characteristics and the like. The address of the called CN, for example the CN's telephone number or another useable address, is comprised in the SDP descriptor. Then, with message 1, the UE sends an INVITE request which comprises the initial SDP, information on the called CN (routing information), a description of the call, the address of the endpoint of the connection on the originating UE side and the like, to the P-CSCF which has been determined, for example, via a CSCF discovery mechanism. The INVITE message is based on the CN's SIP URI (Uniform Resource Identifier). The initial SDP may represent one or more media for a multimedia session. Upon receiving the INVITE message, the P-CSCF stores information about the session, for example the address of the originating UE, and responds with a 100 Trying provisional response (message 2) to the UE. Additionally, the P-CSCF adds headers based on routing information to the message and forwards the INVITE message to the S-CSCF in the UE's home network (message 3). Upon receiving the INVITE message, the S-CSCF stores information about the requested session and responds to the P-CSCF with a 100 Trying provisional response (message 4). Then, in step 5, the S-CSCF performs a service control logic being appropriate for this session attempt. The S-CSCF examines, for example, the media parameters included in the INVITE message and adapts or restricts this to authorization settings for the user. Then, in message 6, the INVITE message is forwarded to the CN. Upon receiving the INVITE message, the CN responds with a 100 Trying message (7) to the S-CSCF. The requests in the INVITE message are processed by the CN, and an 183 Session Progress provisional response indicating the media stream capabilities of the destination node are returned along the signaling path via the S-CSCF (8) to the P-CSCF (9). In the P-CSCF, in step 10, the resources necessary for this session are authorized. Then, the P-CSCF forwards the 183 Session Progress response to the originating endpoint, i.e. to the UE (message 11). Upon receipt of the 183 Session Progress response from the P-CSCF, the UE determines which media flows should finally be used for this session and which codecs should be used for each of those media flows. If there was any change in media flows or if there was more than one choice of codec for a media flow, the UE includes a new SDP offer in a PRACK request message to be sent to the CN. The PRACK, which represents a reliable provisional message for extension requests acknowledgment, is sent to the P-CSCF (message 12), which adds a route header corresponding to the session and transmits the PRACK message to the S-CSCF (message 13). The S-CSCF forwards the PRACK request to the terminating endpoint CN (message 14).
The CN responds to the PRACK request with a 200 OK response to the S-CSCF in order to indicate that it accepts (message 15). The 200 OK response is forwarded by the S-CSCF to the P-CSCF (message 16), which in turn forwards it to the UE (message 17). In step 18, QoS (Quality of Service) setup is performed and the UE determines the final media streams and initiates a reservation procedure for the resources needed for this session. When the UE has completed the resource reservation procedure, it sends a COMET request (message 19), which represents a reliable indication if the preconditions for this session have been met, to the P-CSCF in order to indicate the successful resource reservation. Alternatively, an UPDATE message can be used. The P-CSCF forwards the COMET message to the S-CSCF (message 20), which transmits it to the CN (message 21). The CN responds to the COMET request with a 200 OK response in which a SDP is included for indicating that the resource reservation was successful both in the local and the remote segment. This 200 OK message is transmitted via the S-CSCF (message 22) and the P-CSCF (message 23) to the UE (message 24). Optionally, the called CN may perform alerting. This is signaled to the calling party by means of a 180 Ringing provisional response (message 25). Upon receipt of the 180 Ringing response, the S-CSCF performs in step 26 a service control logic being appropriate for this session attempt. The 180 Ringing response is forwarded to the P-CSCF (message 27). From the P-CSCF, the 180 Ringing response is forwarded to the UE (message 28). The UE indicates to the originating subscriber that the destination is ringing. It responds to the 180 Ringing provisional response with a PRACK request (message 29) to the P-CSCF. The PRACK request is forwarded from the P-CSCF to the S-CSCF (message 30), which then forwards it to the CN (message 31). The CN responds to the PRACK request with a 200 OK response to the S-CSCF in order to indicate that it accepts (message 32). The 200 OK response is forwarded by the S-CSCF to the P-CSCF (message 33), which in turn forwards it to the UE (message 34). The terminating endpoint, i.e. the CN, sends a final response to the INVITE message (message 6) by means of a 200 OK response over the signaling path. This is typically generated when the subscriber has accepted the incoming session attempt. The response is sent to the S-CSCF (message 35). Upon receipt of the 200 OK response, in step 36, the S-CSCF performs service control logic being appropriate for this session completion.
Then the 200 OK response is forwarded to the P-CSCF (message 37). Upon receipt thereof, in step 38, the P-CSCF approves the commitment of the QoS resources for the session. Then, the P-CSCF forwards the 200 OK response to the UE (message 39). The UE can now start the media flow(s) for this session. The UE responds to the 200 OK response with an ACK request sent to the P-CSCF (message 40). The ACK request is forwarded from the P-CSCF to the S-CSCF (message 41), which forwards it to the CN (message 42). Now, the session path is established, i.e. both the UE and the CN knows the respective destination and can send data packets to each other.
Referring to FIG. 3 consisting of FIGS. 3A, 3B, and 3C, a present scenario is described in which a SIP call establishment according to 3GPP and/or 3Gpp2 (cdma2000) is added by a MIPv6 user plane routing optimization. In an environment where SIP is used for multimedia communications setup between an UE and a CN, the MN is setting up the call through the IM subsystem which provides the SIP infrastructure. The IP address of the CN is provided to the MN in the SDP descriptor in the SIP signalling messages. The SIP call establishment has been described above in connection with FIG. 2. The destination address used by the MN (UE) to send the SIP signalling messages is that of the P-CSCF while the IM subsystem routes the SIP signalling messages to the CN. At the IP layer of the protocol stack, the MN recognizes that the end-point of the communication is the CN when the actual media flow begins. In other words, when the CN sends the first user plane packets of the multimedia communication, the IP address of the CN is available to the MIP layer in the MN. The user plane or media plane which is used for routing data packets between the UE and the CN is first established via the home agent (HA) of the MN as the MN's HoA is used as the source address of the SDP of the SIP messages and hence only the MN's CoA is known to the CN. The HA tunnels the user plane packets to the CoA of the MN which is mapped to the MN's HoA in the HA. In the reverse direction, the user plane from the UE to the CN may be also tunneled via the HA. At this point, i.e. after the call has been setup and the media flow has started from the CN, the MN can send a Mobile IPv6 Binding Update message via the HA to the CN since the CN's IP address is derived from the transmitted media flow (user plane). The Binding Update message is sent to the CN after completion of the return routability test. This test requires the exchange of a series of messages defined, for example, in the MIPv6 specification between the MN and the CN. When the Return Routability procedure is successfully finalized, the CN starts to use the CoA as the destination address of the MN. Thus, an optimized routing between the MN and the CN can be established so that the MN (UE) and the CN are directly linked, i.e. user plane traffic can be routed directly to the CoA of the UE and/or of the CN. This avoids the use of long routing paths in the networks.
However, present route optimization techniques in environments implementing network layer sessions (e.g. IP based) and application layer sessions (e.g. SIP based) may provide some drawbacks.
With the current route optimization technique specified, for example, by Mobile IPv6 and the use of SIP to setup a media session, there do exist QoS issues. Since the QoS setup for a multimedia session occurs based on the addresses used by the MN and the CN, the path for QoS setup initially changes once route optimization has been initiated. IP Packets that form the media stream from the CN to the MN have to traverse through the HA all the time and this adds latency.
The resource reservations or QoS parameters for the bearer packets may be done for a path that goes via the MN's Home Agent as a result of the MN providing the Home Address to the IM subsystem and the CN as the IP address in the SDP descriptor. When the MIPv6 Route Optimization procedure is completed, the path changes and QoS may need to be setup again for the changed path. This has implications on added signalling to accomplish this.
Furthermore, the latency of initial packets from the CN to the MN and vice-versa is greater than the latency of packets that are sent after the Route Optimization is completed. Hence there is a change in the characteristics of the flow that can impact the applications and user perceptions.